Modules can be used to share aspects of a rulebase defined in one project with another project (or multiple projects). Information that can be exported through modules includes:
Modules work on the principle of abstraction behind an interface, which means that the user can define which entities, attributes and relationships can be used by other rulebases but information on how those entities, attributes and relationships are used within that module are kept private. This is important because it enables modules to be altered and deployed independently of any other rulebase or module that might use them. For example, if a module author wishes to allow other rulebases to use the goal attribute "the person is eligible for benefit A", along with all the rules that prove it, they need only export that attribute and all the base level entities, attributes and relationships that participate in its proof. If the author subsequently wishes to change the way in which that attribute is proved, they may alter the rules, re-compile and redeploy that module without having to alter any of the rulebases or modules that depend on it (there are certain exceptions to this rule which are detailed below).
Generally, exporting an entity, attribute or relationship is simply a matter of adding it to the project’s external data model by adding a public name to it. More specifically, what gets put into the module interface is determined by the following rules:
Additionally, custom properties, as well as intrinsic properties, on attributes (such as validation, decision report, substitution parameters, "unformatted" flags for number attributes and "display seconds" flags for time of day and date time), entities (identifying attributes) and relationships (decision report parameters) are exported into the module.
Any translations provided in a rulebase for attribute text, validation text and error/warning event message text are also exported into the module.
To build a module, select Build | Build Module from the main menu in Oracle Policy Modeling.
The build process will create the built module file in the project output folder. (The output folder is not visible through Oracle Policy Modeling but can be viewed in Windows Explorer under the project folder.) Note that whenever you build a module, the entire contents of the output directory are deleted. If the build is successful, the only thing you will see in the output folder is the rulebase or module you have just built. If the build is not successful, the output directory will be empty.
During a module build, there are two classes of module specific warnings that may be displayed:
These warnings can be ignored, but may result in unintended behavior of the module.
For information on how to link a module to a rulebase, see Include rules defined in a separate project.
As noted above, a module works on the principle of abstraction behind an interface to allow it to be modified independently of any other rulebase or module that might rely on it. Due to the need to maintain the integrity of the resulting rulebase at runtime there is, however, a limit to what changes can be made to a module without forcing any other rulebase or module that relies on it to also be recompiled.
Simply put, a module can be changed and redeployed without requiring any rulebase or module that relies on it to be recompiled provided the changes do not affect the modules interface. The modules interface consists of the following items:
Additionally, the data model of the interface itself must remain static which means that entities, attributes and/or relationships cannot be added or removed without affecting the interface.
Attempting to deploy a module with an altered interface will cause the engine to refuse to load any rulebase that depends on that module. In such a case, all the modules and rulebases that directly rely on that module must also be recompiled and redeployed. It is also possible that changes to a particular module could cause a loop or multiply proven attribute when that updated module is loaded and the entire rulebase is re-formed at runtime, and this would also result in the rulebase failing to load.
TIP: If you want to be able to update your module independently of the rulebases that rely on it, it is advisable to only export the base level attributes that are required to prove the particular inferred attributes that the parent rulebases use, rather than all the intermediate attributes as well.